Monitoring operational status and detecting faults in a high throughput satellite system

ABSTRACT

A system for monitoring operational status and detecting faults in a satellite system is disclosed. The system may include a processor and a memory storing instructions, which when executed by the processor, cause the processor to select, from a plurality of terminals, a subset of terminals to perform system operation tests. The processor may select the subset of terminals using at least one of a semi-static pre-qualification technique and a dynamic pre-qualification technique. The processor may also perform system operation tests using the selected subset of terminals. The processor may further report results from the system operation test using the selected subset of terminals. In some examples, the processor may also determine potential system operation issues based on the results of the system operation tests, generate an alarm or notification based on the determination of potential system operation issues, and/or abort testing or delay testing to a future testing cycle.

TECHNICAL FIELD

This patent application is directed to satellite communication systems,and more specifically, to systems and methods for monitoring operationalstatus and detecting faults in high throughput satellite (HTS) systems.

BACKGROUND

Advances in telecommunications technologies are increasing availabilityof voice and data services to consumers. These technologicaldevelopments are enabling all types of consumers to transmit and receiveincreasingly larger amounts of multimedia digital content, such texts,streaming audio or video, social media or web content, digitalentertainment, interactive gaming, or other digital content.

Satellite communication systems may be used to provision voice and dataservices. In order to serve more customers and provide higher qualityservice to these customers, high throughput satellite (HTS) systems maybe deployed. High throughput satellite (HTS) systems may support anincrease in numbers of spot beams to cater to growing consumer demand.In order to support the increase in the number of spot beams, acorresponding increase in the number of backend system components may berequired. Managing a higher volume of backend system components,however, may be more challenging, especially when it comes to tending topotentially more malfunctions or defects in these components. Forexample, these defects, deficiencies, or issues may include silentfaults or silent service degradations, which may occur across severalcomponents of the high throughput satellite (HTS) system. Consequently,these faults or degradations, when left unattended, may adversely affectthe health or normal operations of satellite communication systems.Although some satellite system operators may use specialized detectiontools to monitor and/or debug these and other related issues, suchspecialized tools tend to further exacerbate the problems as they mayincrease the complexities in the operation and use of these satellitecommunication systems.

BRIEF DESCRIPTION OF DRAWINGS

Features of the present disclosure are illustrated by way of example andnot limited in the following Figure(s), in which like numerals indicatelike elements, in which:

FIG. 1 illustrates a system for monitoring operational status anddetecting faults, according to an example;

FIG. 2 illustrates a system element for monitoring operational statusand detecting faults in a satellite system, according to an example;

FIG. 3 illustrates a method for monitoring operational status anddetecting faults in a satellite a system, according to an example;

FIG. 4 illustrates a method for selecting and pre-qualifying terminalsfor monitoring health in a satellite system, according to an example;

FIG. 5 illustrates a method for dynamic pre-qualification in a satellitesystem, according to an example;

FIG. 6 illustrates a block diagram of various system operation tests ina satellite system, according to an example; and

FIG. 7 illustrates a block diagram of a computer system for monitoringoperational status and detecting faults, according to an example.

DETAILED DESCRIPTION

For simplicity and illustrative purposes, the present disclosure isdescribed by referring mainly to examples and embodiments thereof. Inthe following description, numerous specific details are set forth inorder to provide a thorough understanding of the present disclosure. Itwill be readily apparent, however, that the present disclosure may bepracticed without limitation to these specific details. In otherinstances, some methods and structures readily understood by one ofordinary skill in the art have not been described in detail so as not tounnecessarily obscure the present disclosure. As used herein, the terms“a” and “an” are intended to denote at least one of a particularelement, the term “includes” means includes but not limited to, the term“including” means including but not limited to, and the term “based on”means based at least in part on.

As described above, high throughput satellite (HTS) systems with largernumbers of spot beams may be used to provision higher quality and morereliable voice and data services to a variety of customers. However, inorder to support the larger number of spot beams, these high throughputsatellite (HTS) systems may require an increase in the number ofcomponents, such as antennas, gateways, data stores, etc. This increasein components may generally correspond with a rise in system complexityand may therefore lead to a greater probability of malfunction ordefects, such as silent faults or silent service degradations. The addedcomplexities may therefore give rise to more challenges in managing ortroubleshooting all the issues associated with the various components ofsuch high throughput satellite (HTS) systems. Specialized detectiontools used by satellite system operators to monitor and/or debug theseand other related issues seem to only add more layers to analready-complicated process to monitor operations and health ofsatellite communication systems.

To address these issues, some satellite communication systems may employone or more health monitor terminals in each spot beam. These healthmonitor terminals may include health monitor very small apertureterminals (VSATs) or HM-VSATs. In this scenario, a health monitor VSATmay be deployed in the spot beam to be monitored amongst and in additionto the customer terminal population (e.g., customer VSATs).

However, employing a dedicated health monitor VSAT in each spot beam mayhighly expensive, and therefore cost prohibitive for many serviceproviders. For instance, the cost for using health monitor VSATs becomesincreasingly more expensive as the number of spot beams grows.Furthermore, these health monitor VSATs may only verify operations ofthe components or paths they use, which in turn may require extensivemanual control to be exercised at all the different services and servicepaths available in the satellite communication system. Consequently,satellite system operators may use these health monitor VSATs to monitorsystem health only after suspecting any system performance problem.Additionally, deploying these types of in-beam health monitoring VSATsmay be impractical for some network configurations. For example, thesemay include systems with satellite user beams over water for maritimeservice or other similar configuration where health monitor VSATs maynot be easily deployed.

Another approach for monitoring system health of high throughputsatellite systems may be to place a health monitor VSAT within orattached to a gateway radio frequency transmission (RFT) rack, which canbe controlled to exercise different paths. It should be appreciated thatthis solution may be typically achieved with suitable frequency and/orlevel conversion and usually without a very small aperture terminal(VSAT) antenna. Although these gateway-resident HM-VSATs may be deployedwith relatively lesser cost compared to dedicated in-beam HM-VSATinstallations described above, a technical issue exhibited by thisapproach is that these gateway-resident terminals may not provide asfull or robust system health reading or report. For example,gateway-resident HM-VSATs typically bypass satellite, local spot beamaffects, and transmission channel health, thus the system operationtests performed may be insufficient in some cases. Furthermore,gateway-resident HM-VSATs may communicate without satellite delay, andmay therefore require manual control to test system health when aproblem is suspected. As a result, anticipating the problem is not onlyimpractical but may only get worse, especially with more spot beams inhigh throughput satellite systems.

Accordingly, systems and methods for monitoring operational status anddetecting faults in high throughput satellite (HTS) systems may beneeded. Satellite communications systems may benefit from solutions orapproaches that are capable of scaling with less cost, as well as thosethat are more efficient and proactive in monitoring operation status anddetecting faults, such as silent faults or other system health problems.As described herein, these faults or degradations, when left unattended,may adversely affect the health of satellite communications systems,placing a premium on satellite communication systems that canaccurately, reliably, and efficiently monitor and detect them.

The systems and methods described herein, however, may opportunisticallyuse customer VSATs, rather than dedicated HM-VSATs or gateway-residentHM-VATs, to periodically test high throughput satellite (HTS) systemhealth, for example, in order to better detect silent faults anddegradations. In addition, the systems and methods described herein mayprovide more proactive test coverage and notification mechanisms, allthat while maintaining lower expense and operating cost. In the examplesdescribed herein, a process or technique may be employed to determinewhich customer terminal may be “pre-qualified” for performing systemoperation or health tests in each beam. In some examples,pre-qualification may be based on terminal capability, permission,priority, current operating status, and/or other pre-qualificationfactors. It should be appreciated that only those terminals that arepre-qualified based on these factors may be identified and used toperform any number of system operation or health tests for any giventest cycle.

Additionally, the systems and methods described herein may enable a testsuite, or package of system operation or health tests, to be adaptive.In other words, the tests that are to be performed by the pre-qualifiedcustomer terminals may or may not significantly increase network loadingduring times of congestion. By identifying the customer terminals thatare capable and available, for example, performing system operationtests using these customer terminals may not may not contribute to fairaccess policy (FAP) calculation of selected user terminals. In this way,the systems and methods for monitoring operational status and detectingfaults in high throughput satellite (HTS) systems, as described hereinmay provide solutions that are more proactive, cost efficient, scalable,and amenable to broader satellite and test coverage. These and otherbenefits and advantages may be apparent in the examples outlined below.

FIG. 1 illustrates a system 100 for monitoring operational status anddetecting faults, according to an example. In some examples, the system100 may depict a satellite communication system capable of providing atleast voice and/or data services. In some examples, the satellitecommunication may be a high throughput satellite (HTS) system. Thesystem 100 may include any number of terminals 110, a satellite 120, agateway 130, a network data center 140, a network management system(NMS) 150, a business system 160, or other various system elements orcomponents. The system 100 may also include a private network 170 and/orpublic network 180. It should be appreciated that the system 100depicted in FIG. 1 may be an example. Thus, the system 100 may or maynot include additional features and some of the features describedherein may be removed and/or modified without departing from the scopesof the system 100 outlined herein.

The terminals 110 may be any variety of terminals. For example, theterminals 110 may be customer terminals, such as very small apertureterminals (VSATs). It should be appreciated that VSATs may be terminalsthat are mounted on a structure, habitat, or other object or location.Depending on application, the terminals 110 may include or incorporateany number of antenna dishes, which may be provided in various sizes,depths, or dimensions (e.g., small, medium, large, etc.). Although theterminals 110 may typically remain in the same location once mounted,the terminals 110 may be removed from their mounts, relocated to anotherlocation, and/or may be configured to be mobile terminals. For instance,the terminals 110 may be mounted on mobile platforms that facilitatetransportation thereof from one location to another. Such mobileplatforms may include, for example, any number of mobile vehicles, suchas cars, buses, boats, planes, etc. It should be appreciated that suchterminals 110 may generally be operational when still and not whilebeing transported. That said, there may be scenarios where the terminals110 may be transportable (mobile) terminals that remain operationalduring transit. As used herein, the terms “terminal,” “customerterminal,” “satellite terminal,” and/or “VSAT” may be usedinterchangeably to refer to these terminal types.

It should be appreciated that any number of customer premise equipment(CPE) (not shown) may be communicatively coupled to the terminals 110.In some examples, the customer premise equipment (CPE) may include anynumber of computing or mobile devices. For example, such a computing ormobile device may include a laptop, a tablet, a mobile phone, anappliance, a camera, a sensor, a thermostat, a vehicle, a display, etc.In general, the customer premise equipment (CPE) may include, withoutlimitation, any number of network-enabled computing devices, elements,or systems. It should be appreciated that a network of such devices maybe commonly referred to as the “Internet of Things” (IoT).

As shown in FIG. 1, there may be a plurality of groups of terminals 110(e.g., customer VSATs). For example, there may be a first group 110A ofterminals 110 and a second group 110B of terminals 110. In someexamples, the first group 110A may be “pre-qualified” terminals. Thesecond group 110B may be “disqualified” terminals. The process andmechanism in selecting, pre-qualifying, and/or disqualifying theterminals 110 will be described in greater detail below. That said, itshould be noted that categorizing the terminals 110 into at least afirst group 110A and a second group 110B may be an important aspect ofmonitoring system health. In some examples, the systems and methodsdescribed herein may recognize that there are terminals 110 (e.g., VSATswith health monitoring capabilities) that are deployed and not activelyin use by customers. By identifying and leveraging these particularterminals 110, the systems and methods described herein may better “loadbalance” existing terminals 110 for monitoring system health, takingaction to avoid depleting customer volume allowance, and without makinguse of purpose-attached or customer owned end-user devices to controltest scenarios, as described below. These and other benefits will beapparent in the examples presented below.

The satellite 120 may be an object intentionally placed into orbit. Insome examples, the satellite 120 may be an artificial satellite that isconfigured to transmit and receive data signals. For example, thesatellite 120 may form one or more beams and provide connectivitybetween at least the terminals 110 and the gateway 130. Morespecifically, the satellite 120 may communicate data signals using thesebeams with the terminals 110 via a terminal return channel 115 a and aterminal forward channel 115 b, and with the gateway 130 via a gatewayreturn channel 125 a and a gateway forward channel 125 b. It should beappreciated that the satellite 120 may form any number of beams tocommunicate data signals with any number of components, even beyond theterminals 110 or the gateway 130 as shown.

In some examples, the satellite 120 may be a communication satellite,such as a high-throughput satellite, which may include any satellitethat is capable of providing at least twice (e.g., 20+ times, 100+times, etc.) the total amount of throughput as a classic fixed-satelliteservice (FSS) satellite. In some examples, the satellite 120 mayinclude, but not limited to, a transponded satellite, a regenerativesatellite, and/or other similar satellite that may generate one or morespot beams. Furthermore, in some examples, the satellite 120 may operatein geosynchronous, mid-earth, low-earth, elliptical, or some otherorbital configuration.

The gateway 130 may include or be communicatively coupled to atransceiver 135, such as a radio frequency transceiver (RFT). Thetransceiver 135 may include an antenna unit of any type (e.g.,transmitter, receiver, communication element, etc.), which may transmitand receive signals. In some examples, the transceiver 135 may beuseable, by the gateway 130 of system 100, to transmit and receive datafrom the terminals 110, via communications from the satellite 120, andmay be configured to route data and traffic from these terminals 110 toany other element or component in the system 100, such as the networkdata center 140 and/or network management system (NMS) 150. The gateway130 may be further configured to route traffic to and from the publicinternet 180 and/or private network 170 across the satellitecommunication channels 115 a, 115 b, 125 a, or 125 b to any terminal110, which would then provide data communications or route traffic toany customer premise equipment (CPE) (not shown) associated with theterminal 110. Although depicted as a single element, the gateway 130 mayinclude a single gateway, multiple gateways residing locally orremotely, in full or in part, relative to the other system components.As described in more detail below, the gateway 130, the network datacenter 140, and/or the network management system (NMS) 150 may provideoperations associated with system health monitoring and fault detection.

For example, FIG. 2 illustrates a system component 200 for monitoringoperational status and detecting faults, according to an example. Asshown, the system component 200 may include the gateway 130 and thenetwork data center 140. Here, the system component 200 may includevarious components, implemented in hardware, software, or a combinationthereof, to facilitate communication between the terminals 110, systemcomponents, private network 170, and public network 180 via thesatellite 120. In some examples, the gateway 130 may include a processor232 (e.g., a computer processing unit (CPU), etc.), a data store 234.While generically illustrated, the processor 232 may include alsovarious configurations including, without limitations, a personalcomputer, laptop, server, etc. The data store 234 may be used, forexample, to store and provide access to information pertaining tovarious operations of and in the system 100. Although depicted as asingle element, the processor 232 and/or the data store 234 may beconfigured as a single element, multiple elements, or an array ofelements. For example, the gateway 130 may include any number ofprocessors and/or data stores in order to accommodate the needs of aparticular system implementation. Various examples may further providefor redundant paths for components of the gateway 130. These redundantpaths may be associated with backup components capable of beingseamlessly or quickly switched in the event of a failure or criticalfault of any primary component.

The gateway 130 may also include other components, such as a basebandcomponent 236, a network interface 238 and a fault management unit 240.In some examples, the baseband component 236 may process signals beingtransmitted to, or received from, the satellite 120. For example, thebaseband component 236 may further include any number ofmodulator/demodulator units, system timing equipment, switching devices,etc. The modulator/demodulator units, for example, may be used togenerate carriers that are transmitted into each spot beam and toprocess signals received from the terminals 110. The system timingequipment may be used to distribute timing information for synchronizingtransmissions from the terminals 110. Other various components or unitsmay also be provided.

The network interface 238 may provide the gateway 130 with an ability tocommunicate with a variety of devices over a network and may include,for example, an Ethernet adapter, a Fibre Channel adapter, and/or otherwired- or wireless-enabled adapter. For example, the network interface238 may allow the gateway 130 to communicate with various networkelements. Although this may be achieved generally via the network datacenter 140, it should be appreciated that each of the gateway 130 and/orthe network data center 140 may also be integrated into a singlefacility, which at times may also be referred to as a “gateway.” In someexamples, the network interface 238 may include at least one edge routerfor establishing connections with a terrestrial connection point from aservice provider. Depending on the specific implementation, however,multiple terrestrial connection points may be utilized. The networkinterface 238 may therefore provide a direct or indirect connection fromone network element to another, and facilitate communication and betweenvarious network elements.

The fault management unit 240 may help monitor activities and output oneor more alerts in the event of a malfunction in any of the gatewaycomponents. In some examples, the fault management unit 240 may include,for example, one or more sensors and interfaces that connect todifferent components of the gateway 130 or other system component. Thefault management unit 240 may also be configured to output alerts basedon instructions received, locally or remotely, from the network datacenter 140 and/or network management system (NMS) 150.

The network data center 140 may be communicatively coupled to thegateway 130, as well as other system components, such as the networkmanagement system (NMS) 150, private network 170, and/or public network180. In some examples, the network data center 140 may be a satellitenetwork data center that is configured to perform protocol processingand bandwidth allocation for gateway traffic and/or VSAT communicationsin the served beams. For instance, as shown in FIG. 2, the network datacenter 140 may include a return bandwidth allocation unit 242, aninternet protocol gateway (IPGW) 244, and a test host 246. The returnbandwidth allocation unit 242 may allow the network data center 140and/or the gateway 130 to allocate return channel access to VSATs inresponse to bandwidth requests. The internet protocol gateway (IPGW) 244help facilitate a traffic processing function, which may allowforwarding and protocol processing between external public networks andprivate networks (e.g., private network 170 and/or public network 180),and gateway communication channels. The test host 246 may help supportcertain health monitor test functions. In some examples, the test host246 may function with the fault management unit 240 of the gateway 130to monitor system health and detect faults, as described herein.Although depicted in FIG. 1 and FIG. 2 as a separate and distinctelement, the network data center 140, in some examples, may becollocated and/or integrated, fully or partially, with the gateway 130,or may be positioned at some other location. Furthermore, although shownas a single element, the network data center 140, in some examples, maybe include a plurality of network data centers that are local or remote,in full or in part, relative to the other system components.

The network data center 140 and the gateway 130 may include many otherfunctions not directly referenced in this description and thereforeomitted for clarity. For instance, it should be appreciated that theprocessor 232 and/or the data store 234, in some scenarios, may also beconfigured as part of the network data center 140 with the IPGW 244 orthe test host 246. Additionally, given architectures might place certainfunctions, such as return bandwidth allocation unit 242 within thegateway 130 rather than within the network data center 140, and mightplace certain functions or elements, such as modems, within the networkdata center 140 rather than within the gateway 130. Such differences arenot material to the design disclosed here. Furthermore, even thoughsystem component 200 is described primarily with respect to the gateway130 and the network data center 140, it should be appreciated that thesystem component 200 of FIG. 2 may also be directed to the networkmanagement system (NMS) 150, the business system 160, and/or any othersystem element. As mentioned above, there may implementations where thesystem 100 and/or system component 200 may utilize any combination ofmultiple gateways, network data centers, network management systems,etc. to perform the system health monitoring features as describedherein.

Referring back to FIG. 1, the network management system (NMS) 150,maintains, in full or in part, various information (configuration,processing, management, etc.) for the gateway 130, and terminals 110 andbeams supported by the gateway 130. It should be appreciated that thenetwork management system (NMS) 150 may or may not be co-located withinthe same physical structure as the gateway 130. Furthermore, the networkmanagement system (NMS) 150 may be single or a plurality distributedcomponents that may be communicatively coupled to each other and/or withother system elements, such as the gateway 130 (e.g., using thepreviously described hardware and external networks). The networkmanagement system (NMS) 150 may, among other things, include aconfiguration manager or other similar management unit. The networkmanagement system (NMS) 150 may also include any number of reportingsystems. As will be discussed in greater detail below, each of thesemultiple reporting systems may be configured to receive differentinformation (e.g., reports) from the terminals 110. External reportingsystems may also be configured to receive information (e.g., reports)from the terminals 110 by establishing a communication link with networkmanagement system (NMS) 150.

The business system 160, or other various system elements or components,may also be communicatively coupled to the network management system(NMS) 150 and/or gateway 130. In some examples, the business system 160may include a virtual network operator (VNO), which may be configured tocommunicate with the gateway 130 and/or the network management system(NMS) 150 in order to monitor the status of its own terminals 110. Moreparticularly, a virtual network operator (VNO), in some scenarios, maybe a business or government entity, that may have access (by purchase orlicense) to a managed service and associated capacity from a satellitenetwork operator in order to provide communication connectivity and/orcommunication for a privately-owned set of terminals 110. The virtualnetwork operator (VNO) may therefore manage various aspects of suchterminals 110 via the gateway 130 and/or the network management system(NMS) 150.

The private network 170 and/or public network 180 may include anyvariety of networks. For example, the private network 170 may be a localarea network (LAN), and the public network 180 may be a wide areanetwork (WAN). That said, the private network 170 and/or public network180 may each also be a local area network (LAN), wide area network(WAN), the Internet, a cellular network, a cable network, a satellitenetwork, or other network that facilitates communication between thecomponents of system 100 as well as any external element or systemconnected to the private network 170 and/or public network 180. Theprivate network 170 and/or public network 180 may further include one,or any number, of the exemplary types of networks mentioned aboveoperating as a stand-alone network or in cooperation with each other.For example, the private network 170 and/or public network 180 mayutilize one or more protocols of one or more clients or servers to whichthey are communicatively coupled. The private network 170 and/or publicnetwork 180 may facilitate transmission of data according to atransmission protocol of any of the devices and/or systems in theprivate network 170 and/or public network 180. Although each of theprivate network 170 and/or public network 180 is depicted as a singlenetwork in FIG. 1, it should be appreciated that in some examples, eachof the private network 170 and/or public network 180 may include aplurality of interconnected networks as well.

While the processors, components, elements, systems, subsystems, and/orother computing devices may be shown as single components or elements,one of ordinary skill in the art would recognize that these singlecomponents or elements may represent multiple components or elements,and that these components or elements may be connected via one or morenetworks. Also, middleware (not shown) may be included with any of theelements or components described herein. The middleware may includesoftware hosted by one or more servers. Furthermore, it should beappreciated that some of the middleware or servers may or may not beneeded to achieve functionality. Other types of servers, middleware,systems, platforms, and applications not shown may also be provided atthe front-end or back-end to facilitate the features and functionalitiesof the system 100, system component 200, and their components, as shownin FIGS. 1 and 2.

The systems and methods described herein may provide a health monitoringsystem that makes use of deployed and pre-qualified customer terminalsto conduct system health checks and report results. As shown in FIG. 1,a population of customer terminals 110 deployed in a user beam mayinclude a first group 110A of “pre-qualified” terminals 110. Theterminals 110 of the first group 110A may be used to conduct healthmonitoring tests, as described below, and the second group 110B, whichmay be designated as “disqualified” terminals 110, may not be used forthis purpose. In this way, those pre-qualified terminals 110 of thefirst group 110A, when not actively in use by customers, for example,may be used to perform any number of system operation or health testswithout contributing to overall usage that depletes a customer volumeallowance, and without making use of purpose-attached or customer ownedend-user devices to stimulate or control test scenarios, such asdesignated HM-VSATs or gateway-resident VSATs.

By identifying capable and available customer terminals 110 that arealready deployed using various pre-qualification techniques, andleveraging these terminals 110 to perform one or more system operationtests, the systems and methods described herein may not requirepurpose-installed health monitor VSAT sites or similar dedicatedequipment, minimizing capital and operational expense. Furthermore, theapproaches described herein may not depend on end-user cooperation ordevices (such as phones or desktop computers). Additionally, the systemsand methods described herein provides an approach that may be fullyscalable using existing equipment, and without interfering with usertraffic performance. Also, the systems and methods outlined herein mayrecognize different capabilities of different terminals to supportdifferent types of system operation test to provide higher levels offlexibility, adaptability, and customizability.

FIG. 3 illustrates a method 300 for monitoring operational status anddetecting faults in a satellite a system, according to an example. Themethod 300 is provided by way of example, as there may be a variety ofways to carry out the method described herein. Although the method 300is primarily described as being performed by the system 100 of FIG. 1and/or the system component 200 of FIG. 2, the method 300 may beexecuted or otherwise performed by one or more processing components ofanother system or a combination of systems. Each block shown in FIG. 3may further represent one or more processes, methods, or subroutines,and one or more of the blocks may include machine readable instructionsstored on a non-transitory computer readable medium and executed by aprocessor or other type of processing circuit to perform one or moreoperations described herein. The system 100 or system component 200, forexample, may perform a health monitoring process on a predeterminedregular interval during normal system operations. In some examples, thismay be an automated sequence of actions, as described below and shown inFIG. 3.

At 310, the terminals 110 may be selected and placed in either the firstgroup 110A of “pre-qualified” terminals 110 or the second group 1108 of“disqualified” terminals 110. For example, the network management system(NMS) 150 may select, from a plurality of customer terminals 110, asubset of customer terminals 110 to perform system operation tests usingat least one of a semi-static pre-qualification technique or a dynamicpre-qualification technique, described in more detail below. At 320, oneor more system operation tests (or health monitoring tests) may beperformed. For example, the network management system (NMS) 150 mayperform these system operation tests using the selected subset ofcustomer terminals 110. The types of system operation tests will bedescribed in more detail below. At 330, results from the one or moresystem operation tests may be generated and/or reported. For example,the network management system (NMS) 150 may coordinate with the gateway130 and/or network data center 140 to report results from the systemoperation test performed by the selected subset of customer terminals110. At 340, alarms associated with potential system problems, based onthe results from the one or more system operation tests, may beidentified and/or generated. Again, the network management system (NMS)150 may coordinate with the gateway 130 and/or network data center 140to identify and/or generate these alarms or notifications. These alarmsand/or notifications may be based on problems or issues uncovered by thesystem operation tests performed by the customer terminals 110. At 350,a delay may be initiated depending the problems identified. In someexamples, there may be a delay of performing system operation testsuntil a next test cycle.

Although the method 300 may be continuous or automatic, it should beappreciated that the method 300 may be suspended at any time, based onoperator command or automatically by the NMS during certainextraordinary operations, such as major maintenance or upgrade activityor for other reasons. Details for each of these actions will not bedescribed in greater detail below.

FIG. 4 illustrates a process by which system 100 may select andpre-qualify 310 terminals 110, according to an example. As shown,selecting and pre-qualifying 310 terminals 110 may include performing asemi-static pre-qualification technique 400 and/or performing a dynamicpre-qualification technique 500. Again, an appropriate set of terminals110 may need to be selected and pre-qualified to order to be able tocheck or monitor the various spot beam communication channels,resources, and/or services of the satellite system. At least part of theselection and pre-qualification 310 may include identifying certainpre-qualification factors exhibited by the terminals 110. For instance,in order to be used for health monitoring, the terminals 110 may need tobe in the targeted spot beams, have certain health monitoringcapabilities, and/or be available or capable to perform one or morespecific system operation tests.

In some examples, the semi-static pre-qualification 400 may be providedas a first action to select and pre-qualify the terminals 110 toidentify a set or subset of candidate terminals, from a plurality ofcustomer terminals 110, for health monitoring. It should be appreciatedthat the semi-static pre-qualification 400 may be performed frequently(e.g., continuously at predetermined short-term intervals) orinfrequently (e.g., once a day, once a week, once a month). In someexamples, the semi-static pre-qualification 400 may be performed asinstructed by a system operator. In most applications and in general,the semi-static pre-qualification 400 may be performed infrequentlysince terminal capabilities and permissions may be unlikely to changefrom one test cycle to another test cycle.

For the semi-static pre-qualification 400, it should be appreciated thata system operator may configure a set of deployed terminals to becandidates for use for health monitoring in each satellite beam, througha user interface, spreadsheet list, and/or machine-to-machine interface,in which case this action is trivial and ends. In addition oralternatively, the network management system (NMS) 150 may coordinate orperform a set of pre-qualification actions to determine a set ofdeployed terminals to be candidates for use for health monitoring ineach satellite beam. For example, referring back to FIG. 4, thesemi-static pre-qualification 400 may involve the selecting andpre-qualifying terminals 110 based on any one of a variety ofpre-qualification factors. These pre-qualification factors may include,but not limited to, whether a terminal is within a target beam, anyconfigured permission(s), terminal capacity, terminal capability,service plan, channel mapping, monitoring priority, in-beam location,and/or any other pre-qualification factor or combination thereof.

In identifying terminals 110 based on beam location, the networkmanagement system (NMS) 150, for example, may identify a set ofterminals 110 that are deployed and activated within each targetsatellite user beam. As a result of filtering terminals 110 using thispre-qualification factor (e.g., whether the terminal 110 is within atarget beam for performing system operation tests), any terminals 110that are positioned in other (non-target) beams may be excluded.

In identifying terminals 110 based on configured permission, the networkmanagement system (NMS) 150, for example, may identify or select thoseterminals 110 which may be designated as permitted to be used for healthmonitoring and thereby exclude those terminals 110 which are notpermitted for use. It should be appreciated that such configurepermission(s) may be predetermined. For example, such permission may beindicated by a business system 160 during or following a terminalconfiguration or activation process, or possibly as granted or notgranted by an end user or customer. In some situations, it may be thecase that a customer contract or some local regulation prohibits use ofcertain customer VSATs 110 for network monitoring purposes. In somescenarios, it may be the case that the customer is given an opt-in oropt-out capability via a network management or business system portalassociated with the network management system (NMS) 150 and/or businesssystem 160, which may be in exchange for some consideration such as ahigher download allowance or other similar incentive or bargain-forconsideration. In other situations, it may be the case that specificVSAT site factor(s) may need to be considered. For example, there may bea specific VSAT site factor that prohibits using terminals that aresolar powered with battery storage. These and other configurepermission(s) may be used as part of the terminal pre-qualification.

Terminal capability may be another pre-qualification factor. Forexample, the network management system (NMS) 150 may select terminals110 have the capabilities to perform targeted tests and exclude thoseterminals 110 that are not capable of performing these tests, especiallyin situations where such differentiation may be applicable. For example,there may be a situation where a newer generation of terminals aredeployed or terminals that are running a newer software release hascertain capabilities not available in an older generation of terminalsor terminals that have yet been updated by that software release. Theseolder terminals or non-updated terminals may lack capabilities toperform specific system tests as part of the process for monitoringsystem health. It should be appreciated that there may also be scenarioswhere certain terminals are deployed with certain communication channelcapabilities and other terminals are deployed with other communicationchannel capabilities, where these sets of capabilities may not be fullyoverlapping, and where both sets may need to be tested. In suchsituations, for example, it may be important to prequalify two or moresets of candidate health monitor VSATs to provide the desired testcoverage. Other similar combinations or permutations may also beprovided.

Pre-qualification based on service plan or channel mapping may also beprovided. In so far as gateway equipment or communication channels aremapped to specific service plans, the network management system (NMS)150 may partition the candidate terminals 110 into sufficient candidatesub-lists to provide test coverage of all equipment and paths to bechecked. A point to consider here may be that in the event thatexecuting tests would cause a change to a user perceived environment,for example, reassignment of a dynamic internet protocol (IP) subnetaddress, or disconnect of an active transmission control protocol (TCP)connection, then multiple partitions of test VSATs may be selected toavoid or minimize such impact. In other words, such an approach may besystem specific, and although such partitioning could potentiallyintroduce more complexity into the pre-qualification process, it shouldbe appreciated that a straightforward hardware/software design activitymay be provided.

Monitoring terminal priority may also be another pre-qualificationfactor for selecting candidate terminals 110. Although the system 100described herein may provide a way to monitor VSAT health withoutrequiring dedicated, purpose-installed health monitoring terminals, itshould be appreciated that in some situations the system operator, forwhatever reason, may choose to deploy health monitoring VSATs in certainhigh-value or low-cost locations (such as at a gateway site). In thisscenario, those particular terminals, which may not be customerterminals, may be deemed as preferred or have some level of priority forinclusion in pre-qualification, e.g., the dynamic pre-qualification 500.In addition or alternatively, it may be that an enterprise servicecontract not only permits, but calls for VSATs of that enterprise, to beused on a non-interfering basis to opportunistically verify site (ratherthan system) health. In this case, these prioritized terminals 110 mayhave preference for being used as pre-qualified terminals. There mayeven be some scenarios where a customer may be incentivized to allowtheir terminals to be prioritized. The incentives may include afinancial incentive, upgraded service, or other incentive. In this way,customers may opt-in to allow their terminals 110, which may bewell-positioned within a beam or have upgraded capabilities, to alsohave monitoring priority to be used to perform system operation testsbefore other candidate terminals are to be considered.

In-beam location may also be another pre-qualification factor, ifapplicable. In some examples, there may be value to prioritize terminals110 that are near the edge of a satellite user beam, near the center ofthe beam, or other location within the beam. If such in-beamprioritization exists, then those terminals 110 that fit a particularin-beam pre-qualification position may have preference to serve ascandidate health monitor VSATs, and therefore this may be another factorto consider during performance of the semi-static pre-qualificationtechnique 400.

It should be appreciated that these pre-qualification factors areillustrative examples, and that there may be other factors not listedthat may also be provided as part of the semi-static pre-qualification400 process. It should also be appreciated that any one of thesepre-qualification factors or other factors may be used, individually orin any combination and in any sequence, to narrow down the list ofcandidate terminals 110 that may be used to help formulate the firstgroup 110A of terminals for system health monitoring. In some examples,those terminals 110 that are selected and pre-qualified based on thesemi-static pre-qualification technique 400 may be further narrowed byperforming dynamic pre-qualification 500, as described herein.

The semi-static pre-qualification technique 400 may be performedautomatically by system 100 and may be relatively infrequent since thepre-qualification factors may not typically change too often. Althoughthe semi-static pre-qualification technique 400 may be performediteratively at any time, it may be useful for the semi-staticpre-qualification technique 400 to be performed anywhere in the range ofminutes, days, weeks, or months. In some examples, the semi-staticpre-qualification technique 400 may be performed every 1 or 2 days.

In some examples, the dynamic pre-qualification technique 500 may beused to determine a subset of candidate terminals based on any givenhealth monitoring test cycle. For example, the dynamic pre-qualificationtechnique 500 may help narrow a subset of terminals 110 forpre-qualification based on current terminal status, etc. FIG. 5illustrates a method 500 for dynamic pre-qualification in a satellitesystem, according to an example. As described above, the semi-staticprequalification technique 400 may be used to help identify VSATs thatare candidates to be used for health monitoring, but it might be thecase that those terminals 110 may still not be entirely suitable for usein a given health test cycle.

For example, there are a number of reasons why terminals 110 that were“pre-qualified” by the semi-static pre-qualification technique 400 maynot be suited to be include in the final subset of terminals to performone or more system health tests. For instance, a terminal may be poweredoff or impaired by a weather condition. In another example, the terminalmay be in use by the end customer, which means that executing healthmonitor tests might interfere with concurrent customer service. Also,the terminal might be in process of some transition that would make itinadvisable to use, or make it made more complicated by concurrenthealth monitor testing. For example, this terminal may be a mobile VSATnearing a spot beam boundary and a handover trigger, a VSAT in theprocess of downloading new software to be executed, or a VSAT performingsome other complex operation. As a result, even if semi-staticprequalification may identify or select a subset of potential terminalcandidates, dynamic pre-qualification 500 may still be needed. Suchdynamic pre-qualification 500 may be based on a more immediate terminalstatus at a time closer to when actual testing will be needed. As aresult, the dynamic pre-qualification technique 500 may be performed asneeded, and anywhere within the range of seconds, minutes, days, andweeks.

In this scenario, the system 100 may further narrow qualified terminalsfor any given monitoring cycle by executing the dynamicpre-qualification technique 500, as described here. This technique 500,for example, may include the network management system (NMS) 150selecting more candidate VSATs than are needed to conduct a given test,querying immediate status of those VSATs, discarding those withunsuitable status, and/or selecting at least a minimum number of testsites from among the remaining qualified sites. In some examples, theinitial dynamic pre-qualification technique 500 and narrowing selectionmay be based on initially those candidate terminals selected oridentified from the semi-static pre-qualification 400. Here, the dynamicpre-qualification selection 500 may be performed for each monitoringtest cycle, or less often, for example once day, but the immediatestatus query action and pre-qualification may be performed for each testcycle. The technique 500 for dynamic pre-qualification may be asfollows.

At 510, the network management system (NMS) 150 may select a number ofcandidate VSATs from the semi-static pre-qualified candidate list ofterminals. This may be the entire set or subset of candidate VSATs fromthe semi-static pre-qualified candidate list, or may be an entirelydifferent set of VSATs, to perform system operation tests. At 520, thenetwork management system (NMS) 150 may transmit a dynamicpre-qualification status query to each of those candidate VSATs from theselected candidate terminals. Each of the queried VSATs, in response tothe dynamic pre-qualification status query, may perform any number ofstatus self-checks and may send one or more replies to be received andcollected, at 530, by the network management system (NMS) 150.

In some examples, this set of status self-checks may be used to helpdetermine whether the terminal is able to be used to perform systemoperation tests. For example, the status self-check may include any ofthe following: terminal state, user activity, transmission link quality,transmission link reliability, or any other status check. The VSAT statestatus check may help identify that a VSAT is in normal operatingcondition, is it in some contingency state (such as coming up ordownloading software), or is it in some transition state (such as amobile terminal about to transition to a new beam).

The user activity status check may be based on aggregatetransmit/receive bytes over a configured preceding duration, such as theprevious five (5) minutes. Other factors may include, for example, notperforming tests if a customer voice over IP call is in progress, orother traffic-based consideration.

The transmission link quality status check may be based on, for example,a forward or return path adaptive coding and modulation (ACM) modulationconstellation (ModCod). It should be appreciated that a forward path maybe from a gateway 130 to terminal 110, and a return path may be from aterminal 110 to gateway 130. Thus, a terminal 110 that has adapted to avery robust modulation constellation (ModCod) may be indicative of localrain or poor pointing, making that VSAT a poor candidate to run one ormore system health tests.

The transmission link reliability status check may be based on theaveraged packet or frame error rate over a recent period, such as theprevious five (5) minutes. A high error rate, in some examples, may beindicative of either a site-specific problem or a system level problem,and due to this ambiguity, such terminals may be excluded.

The terminal (e.g., VSAT), network management system (NMS) 150, or both,or some other combination of system components may determine whether ornot the terminal can support the test. For example, the VSAT may declinebased on a variety of reasons. A terminal, for instance, may declinebased on an operating state (e.g., a mobile terminal about to move to anew beam) or on some threshold such as user activity level, or the VSATmay return applicable statistics or status to the network managementsystem (NMS) 150 to compare against thresholds, in which case thenetwork management system (NMS) 150 might disqualify the VSAT.

Once these status check responses are received and collected from eachof the queried terminals, the network management system (NMS) 150 mayfilter out those terminals that cannot support the desired system healthtests, or from which no response was received, based on determining, at540, sufficiency of the responses. In some examples, it should beappreciated that a predetermined threshold may be set so that insituations where the responses are insufficient, either in quality,quality, or other insufficiency (e.g., responses do not meet or exceededa predetermined number or percentage of terminal responses, the networkmanagement system (NMS) 150 may generate, at 545, an alarm ornotification for possible beam or system health problem(s). In thiscase, the network management system (NMS) 150 may decide to delay orabort 550 any further dynamic pre-qualification 500.

However, if the responses are determined to be sufficient (e.g., bymeeting predetermined thresholds), the network management system (NMS)150, at 560, may filter out the disqualified terminals, and at 570, thenetwork management system (NMS) 150 may select from the resulting set(s)of pre-qualified terminals, a number of terminals to perform healthtests for each target beam. It should be appreciated that these selectedterminals may comprise a quantity from each candidate list partition orthey may be randomized across the candidate set on a priority basis.

Each VSAT may execute a health monitor test suite on receipt of acommand from the network management system (NMS) 150 to do so, and thenreport its test results to the network management system (NMS) 150. Thetest suite may be defined so as to be performed by the operationalsoftware release that is integral to the VSAT. This may be achieved, forexample, without reliance on external test or customer devices.

Depending on the duration of the test, it may be the case that thecustomer becomes active using the VSAT during the test. In such case, orif the VSAT state otherwise changes such that it is no longer qualifiedto complete the test suite, the VSAT may abort the test and may return atest abort message to the network management system (NMS) 150. Thismessage, for example, may include partial test results, if applicable,or test results may be reported through other methods, techniques, orchannels.

It should be appreciated that the VSAT may perform any number of systemoperation tests from the health test suite without depleting anypurchased user download or upload volume allowance. For example, thismight be achieved by any of several methods. First, the test suite startand end may be signaled to a gateway 130 peer component (such as an IPGW244) that manages the VSAT volume usage accounting, informing that peercomponent to either not count intervening traffic in usage accounting,or else to account for it as test traffic that is not considered in thecustomer volume allowance.

Second, the test may mark each test traffic message accordingly usingfor example a bit flag in an over-satellite adaptation header, such thatthe gateway 130 peer component does not count that traffic in usageaccounting, or accounts for it as test traffic.

Third, the customer may also be given a one-time volume allowance bumpbeyond the contract volume allowance when the VSAT is selected for agiven test. Here, the volume bump may correspond to the maximum trafficthat is generated by the test. In this case, it may be important toidentify this allowance bump and test traffic volume on any customerviewable usage meter or site to avoid future misunderstanding.Alternatively, the VSAT may be given a recurring volume allowance bumpwith each new volume accounting period, for example in return for optingin to permit the VSAT site to be used for system health monitoring,whether that VSAT is used to run tests or not. The recurring volumeallowance bump, in some situations, may be sufficient to make up for themaximum possible aggregate test traffic contribution during the volumeaccounting period, and the actual test traffic volume may be included inthe user usage accounting, and would also be separately counted andshown on some customer viewable usage meter or site to avoid futuremisunderstanding.

The VSAT health test suite may also be executed to not be accounted inan overall system or per-beam or per-channel capacity subscription of avirtual network operator. Similar mechanisms or techniques, as describedherein, to identify test traffic may be employed such that the gateway130 or network data center 140 may recognize and exclude such trafficfrom virtual network operator (VNO) accounting.

Although the dynamic pre-qualification technique 500 is described asbeing performed after the semi-static prequalification technique 400, itshould be appreciated that the techniques 400 or 500 may be performed inany order, alone or in combination, depending on the system healthmonitoring needs of the system 100, and such pre-qualification may bepredetermined by the system 100 automatically or by an administrator,such as a system operator.

FIG. 6 illustrates a block diagram 600 of various system operation testsin a satellite system, according to an example. There may be any numberof system operation tests that a terminal 110 from the pre-qualifiedfirst group 110A may perform as part of a system health check or healthmonitoring cycle. As shown, these system operation tests may include,but not limited to, the following groupings: traffic tests 610, businesslink tests 620, application tests 630, forward channel coverage tests640, and/or return channel coverage tests 650. In any particular systemhealth check, some or all of these tests, may be performed by thepre-qualified terminals 110 of the first group 110A in any order. Thesetest types and considerations for their use are described in more detailbelow.

In some examples, the traffic tests 610 may include, but not limited to,response time 611, user datagram protocol (UDP) download 612,transmission control protocol (TCP) download 613, user datagram protocol(UDP) upload 614, transmission control protocol (TCP) upload 615, domainname system/service (DNS) 616, HTTP/HTTPS access 617, or other traffictest. It should be appreciated that for the response time test, theterminal may send one or more messages to a test host within the gateway130, network data center 140, or the network management system (NMS)150, and may receive responses, measuring, for example, the averageround-trip response time. The test may pass if sufficient responses arereceived, or alternatively within a predetermined time threshold. Itshould be appreciated that the response time test may include an ICMPping or other similar test.

For user datagram protocol (UDP) download 612, the terminal 110 mayrequest a user datagram protocol (UDP) data transfer from a test hostwithin the gateway 130, network data center 140, or the networkmanagement system (NMS) 150, verifying successful transfer and measuringa packet error rate (missed or corrupted packets) and throughput. Thetest may pass if the test file is received, or alternatively at below apredetermined packet error rate threshold. The test pass criteria mayalso include meeting at least a minimum download rate, possibly asscaled to the forward channel rate and current average loading. Itshould be appreciated that download (and upload) throughput criteria maynot be used in event the terminal is being rate-throttled due toexceeding some volume allowance quota, or such status may be used todisqualify a terminal from being selected in the dynamicpre-qualification process.

It should also be appreciated that it may be important to avoidaffecting other customer traffic if the forward channel is congested. Inthis case, there may be two actions that may be taken. In one action,the terminal may scale the size of the data transfer requested based onforward channel loading, for example with threshold values for averagepercent channel utilization over a period such as the preceding 10seconds. In this manner, the terminal may not contribute a big downloadto forward channel loading if capacity is congested. As another action,the terminal may delay start of this test (or all health check tests)within some randomization time window, such that multiple terminalsselected to perform health tests in a beam at a given test cycle may notsimultaneously contribute load. In some examples, an “iperf” tool builtinto operating systems, such as Linux®, Windows®, etc., may be suitableto perform a UDP (or TCP) download (or upload) test. It should beappreciated that it might be helpful to perform this and other testsusing IPv4 and IPv6, especially if the network supports both IPversions.

For transmission control protocol (TCP) download 613, the terminal 110may request a transmission control protocol (TCP) data transfer from atest host within the gateway 130, network data center 140, or thenetwork management system (NMS) 150, verifying successful transfer andmeasuring a packet transmission control protocol (TCP) retransmit rateand throughput. The test may pass if the test file is received, oralternatively at below a transmission control protocol (TCP) packetretransmission rate threshold. The test pass criteria may also includemeeting at least a minimum download rate. Similar actions may also betaken to avoid introducing network congestion as are described above foruser datagram protocol (UDP) download. It should be appreciated thattransmission control protocol (TCP) download and upload may be tested inaddition to user datagram protocol (UDP) in event the satellite networkimplements a transmission control protocol (TCP) performance enhancingproxy (PEP), which may be implemented for geosynchronous satellitesystems.

For user datagram protocol (UDP) upload 614, the terminal 110 mayinitiate and perform a user datagram protocol (UDP) data transfer to atest host within the gateway 130, network data center 140, or thenetwork management system (NMS) 150, verifying successful transfer andmeasuring a packet error rate (missed or corrupted packets) andthroughput. The test may pass if the test file is delivered, optionallyat below a packet error rate threshold. The test pass criteria may alsoinclude meeting at least a minimum upload rate. As with downloads, itmay important to avoid affecting other customer traffic if returnchannel capacity is congested, and the terminal may scale the uploadfile size according to gateway-advertised return channel loading.

For transmission control protocol (TCP) upload 615, the terminal 110 mayinitiate and perform a transmission control protocol (TCP) data transferto a test host within the gateway 130, network data center 140, or thenetwork management system (NMS) 150, verifying successful transfer andmeasuring a packet transmission control protocol (TCP) retransmit rateand throughput. The test may pass if the test file is delivered, oralternatively at below transmission control protocol (TCP) packetretransmission rate threshold. The test pass criteria may also includemeeting at least a minimum upload rate. Similar actions may be taken toavoid aggravating network congestion as are described above for userdatagram protocol (UDP) upload 614.

In traffic tests 610 that involve DNS service 616, the terminal 110 mayconfirm availability of the DNS resolution service by sending to its DNSserver, in the gateway 130 or network data center 140, a DNS resolutionrequest for a (well-known) domain name, and may confirm a correspondingname resolution is received within some time threshold. It should beappreciated that the terminal 110, in some examples, may require tofirst flush any entry it has for that domain name from a local DNS cachewithin the VSAT.

For hypertext transfer protocol (HTTP) and hypertext transfer protocolsecure (HTTPS) access 617, the terminal 110 may confirm availability ofweb browsing service by sending a web page request to a test host withinthe gateway 130, network data center 140, or the network managementsystem (NMS) 150, and verifying successful download of the test webpage. The test may pass if the complete web page is received, oralternatively in under a target response time threshold value. In theevent the system 100 implements hypertext transfer protocol (HTTP)pre-fetch acceleration, separate tests may be performed for a hypertexttransfer protocol (HTTP) accessible page and a hypertext transferprotocol secure (HTTPS) accessible page.

In some examples, business link tests 620 may be performed. The system100, for example, may include certain customer accessible web hosts toenable customers to monitor their usage, to pay bills, to respond tosurveys or conduct self-help, or for other functions consideredimportant to system operation and health. In these cases, the healthmonitoring test suite executed by the VSAT may include tests to verifyavailability to connect to these hosts and access content. For instance,the VSAT may be configured with a set of URLs for business link tests620, with indication to use hypertext transfer protocol (HTTP) orhypertext transfer protocol secure (HTTPS) for access. In addition oralternatively, the VSAT may access each URL using HTTP or hypertexttransfer protocol secure (HTTPS) as configured, with the test passing ifeach page is successfully downloaded. It should be appreciated that thismay be a generic page access. In other words, the VSAT may not beconfigured with customer-owned account/password information, as this maybe a test of business system availability over the satellite network,rather than a test of individual customer data access.

Targeted application tests 630 may also be performed. In some examples,customers may purchase service to download content from and uploadcontent to desired Internet and Intranet hosts, and the VSAT healthmonitoring test suite may include confirming ability to access certainhigh-value Internet or Intranet URLs, for example, Google®, Facebook®,Netflix®, YouTube®, and the like. A listing of high value URLs to bechecked may be configured in the terminal 110. Here, the terminal mayaccess each of these URLs in turn, using hypertext transfer protocol(HTTP) or hypertext transfer protocol secure (HTTPS) as configured, withthe test passing if each web page is successfully downloaded.

In the even these tests are performed, it should be noted that there maybe several important considerations to be taken into account. First, thetest, in some examples, may access a top-level page only, and may notlog onto a host site using a customer-owned account/password, nor anetwork-owned account/password. In the latter case, for example,downloading a Netflix® or YouTube® video from many sites each using anetwork-owned VSAT-specific account may introduce nuisance loading intothose business operations, and if done using a common network-ownedaccount, such businesses may likely detect many different sitesaccessing the same account and take protective action that could affectthe end customer. Second, the access to such hosts may likely be from anIP address recognizable as a network test address, not attributable toan end-customer, in event of monitoring by law enforcement authorities.Third, access to such hosts may likely be from an IP address that wouldnot allow attacks from external networks (such as the Internet) to reacha VSAT management/test agent, but which would allow the target URL hostto respond to the web page request being tested.

Forward channel coverage tests 640 and return channel coverage tests 650may also be performed. The terminals 110 may be provisioned withmultiple forward communication channels within a given beam, and it maybe beneficial to test the health of each such channel. Each channel, forexample, may utilize different sets of equipment in the gateway 130, anyset which may have a silent failure. Additionally, each channel may alsobe independently interfered with by some outside noise source. Thus,there may be a few possibilities to achieve forward channel coveragethat are described below. First, for systems in which the VSAT is agileto move between forward channels and gain service (e.g., the VSAT iscompatible with each channel type), the VSAT service plan may beavailable using each forward channel, and there may otherwise be norestrictions (such as virtual network operator (VNO) capacity contracts)that would prevent a given VSAT from being used to test multiple forwardchannels. In this case, the VSAT may cycle between the available forwardchannels, conducting at least one user datagram protocol (UDP) ortransmission control protocol (TCP) download test on each such channel,before returning to its starting channel or else selecting a new endingchannel for ongoing service. This movement, in some examples, may bedetermined by the VSAT, and/or in cooperation with some gateway forwardchannel load balancing entity.

Second, for systems in which either the VSAT is not agile, is notcompatible to test all forward channels types, cannot gain service via agiven channel, or is limited due other restrictions (such as VNOcapacity contracts), the network management system (NMS) 150 may insteadpre-qualify a different set of VSATs to conduct tests in each suchgrouping for a given health monitoring cycle.

It should be appreciated that for systems that employ adaptive codingand modulation (ACM) on forward channels, such as by using the DVB-S2standard, the VSAT test may optionally cycle through a set of ACMmodulation constellation (ModCod) values, verifying operation or anerror rate below threshold for each test modulation constellation(ModCod). Other various alternatives may also be provided.

For return channel coverage tests 650, the terminals 110 may beprovisioned with multiple return channels in a beam, and it may bebeneficial to verify the operation of each such channel. In someexamples, two types of channel must be considered: (1) contentionchannels, and (2) allocated channels.

For (1) contention channels, a listing of available contention channelsmay be advertised by a gateway 130 and a channel for use selected by theVSAT. As a result, a VSAT conducting health tests may cycle through theset of advertised contention channels, testing each in turn. A test, inthis case, may comprise sending a message on each given channel thatwill elicit some response, and confirming the response is received.Given the contention nature of such channel access, there may be someprobability that a request will be lost due to a channel accesscollision with another VSAT. Consequently, testing contention channelsmay entail making some number of requests on a given channel andverifying that some threshold percentage of requests result insuccessful responses.

For (2) allocated channels, higher bandwidth channels may be allocatedby some entity in the gateway 130 or network data center 140, inresponse to a terminal request on a contention channel (or on some otherallocated channel). In this operation, cooperation with the returnbandwidth allocation unit 242 may be required for a VSAT to receiveallocations enabling it to cycle through the available return channelsfor a given system health test cycle. In some examples, this may beachieved in different ways, depending on the capabilities of the systemunder test. First, the gateway bandwidth allocation entity, having beeninformed a VSAT is performing a return channel coverage test, may builda list of channels for the terminal to test, and provide allocation toeach in turn when requested. Second, the terminal 110 may build a listof channels to test, and send a special return channel test allocationrequest to the Gateway to get allocation for each channel in turn. Thus,for systems that employ adaptive coding and/or modulation (ACM) onreturn channels, the VSAT test may optionally cycle through a set of ACMmodulation constellation (ModCod) values, verifying operation or anerror rate below threshold for each test modulation constellation(ModCod). Other various options may also be provided.

Referring back to method 300 of FIG. 3, the system 100 or systemcomponent 200 may report 330 system operation test results. In someexamples, a terminal 110 may send health check test results in a messageto the network management system (NMS) 150 upon completing a directedtest sequence. The system operation test results may include an overallpass-fail result, pass-fail result for each individual system operationtest with specific measure values, specific measured values for whichpass-fail is determined based on comparing to predetermined thresholds,a time of the performed system operation test, and/or any other result.What is collected and/or outputted may also be configurable orcustomized by the system 100 automatically or by a system operator.

The network management system (NMS) 150 may log pass/fail results aswell as measured values into a performance database to provideshort-term reporting as well as long term performance trendingcapability. For example, the network management system (NMS) 150 mayprovide the results for display to the operator of the latest responsetime or download throughput metrics for each beam, highlighting thosethat do not meet target threshold criteria. Additionally, the networkmanagement system (NMS) 150 may provide various graphical trend displaysof measured results over time, for example, throughput over time of day(which might be expected to show differences in busy periods due tocongestion) or average throughput within a designated time window for agiven beam over an extended period. Again, the results and displays ofthe results may be customizable or configured by the system 100 orsystem operator.

In the even the system operation test results indicate a potentialsystem operation or health issues, the system 100 may generate, at 340,an alarm or notification based on the determination of potential systemoperation issues. For instance, the network management system (NMS) 150may generate any number of alarms or notifications for the system 100,based on results across multiple similarly-situated VSATs within a beam.Particularly, the network management system (NMS) 150 may decide not togenerate an alarm if one out of five VSATs conducting a test cycle in abeam reports failure of a given test. However, the network managementsystem (NMS) 150 may generate an alarm if more than two of five VSATsreport failure of the same test. Different alarm severity levels may beapplied depending on the percentage of failing VSATs. In other words, apredetermined threshold may be provided based on percentages, type ofpotential system health problem, terminal reliability, etc.

It should be appreciated that results from terminals that abort testcycles due to user activity or other state changes may also not beconsidered, other than for those tests completed. As described above,the network management system (NMS) 150 may also generate an alarm ifunable to get dynamic pre-qualification responses from a certain numberof candidate terminals for a given beam, or if it does not receive atest result report from some percentage of terminals initiated for test.

FIG. 7 illustrates a block diagram of a computer system for monitoringoperational status and detecting faults, according to an example. Thecomputer system 700 may be part of or any one of the terminals 110, thegateway 130, the network data center 140, the network management system(NMS) 150, the business system 160, as shown in system 100 and/or 200 toperform the functions and features described herein. The computer system700 may include, among other things, an interconnect 710, a processor712, a multimedia adapter 714, a network interface 716, a system memory718, and a storage adapter 720.

The interconnect 710 may interconnect various subsystems, elements,and/or components of the computer system 700. As shown, the interconnect710 may be an abstraction that may represent any one or more separatephysical buses, point-to-point connections, or both, connected byappropriate bridges, adapters, or controllers. In some examples, theinterconnect 710 may include a system bus, a peripheral componentinterconnect (PCI) bus or PCI-Express bus, a HyperTransport or industrystandard architecture (ISA)) bus, a small computer system interface(SCSI) bus, a universal serial bus (USB), IIC (I2C) bus, or an Instituteof Electrical and Electronics Engineers (IEEE) standard 1394 bus, or“firewire,” or other similar interconnection element.

In some examples, the interconnect 710 may allow data communicationbetween the processor 712 and system memory 718, which may includeread-only memory (ROM) or flash memory (neither shown), and randomaccess memory (RAM) (not shown). It should be appreciated that the RAMmay be the main memory into which an operating system and variousapplication programs may be loaded. The ROM or flash memory may contain,among other code, the Basic Input-Output system (BIOS) which controlsbasic hardware operation such as the interaction with one or moreperipheral components.

The processor 712 may be the central processing unit (CPU) of thecomputing device and may control overall operation of the computingdevice. In some examples, the processor 712 may accomplish this byexecuting software or firmware stored in system memory 718 or other datavia the storage adapter 720. The processor 712 may be, or may include,one or more programmable general-purpose or special-purposemicroprocessors, digital signal processors (DSPs), programmablecontrollers, application specific integrated circuits (ASICs),programmable logic device (PLDs), trust platform modules (TPMs),field-programmable gate arrays (FPGAs), other processing circuits, or acombination of these and other devices.

The multimedia adapter 714 may connect to various multimedia elements orperipherals. These may include a devices associated with visual (e.g.,video card or display), audio (e.g., sound card or speakers), and/orvarious input/output interfaces (e.g., mouse, keyboard, touchscreen).

The network interface 716 may provide the computing device with anability to communicate with a variety of remove devices over a network(e.g., private network 170 or public network 180 of FIG. 1) and mayinclude, for example, an Ethernet adapter, a Fibre Channel adapter,and/or other wired- or wireless-enabled adapter. The network interface716 may provide a direct or indirect connection from one network elementto another, and facilitate communication and between various networkelements.

The storage adapter 720 may connect to a standard computer-readablemedium for storage and/or retrieval of information, such as a fixed diskdrive (internal or external).

Many other devices, components, elements, or subsystems (not shown) maybe connected in a similar manner to the interconnect 710 or via anetwork (e.g., private network 170 or public network 180 of FIG. 1).Conversely, all of the devices shown in FIG. 7 need not be present topractice the present disclosure. The devices and subsystems can beinterconnected in different ways from that shown in FIG. 7. Code orcomputer-readable instructions to implement the dynamic approaches forpayment gateway selection and payment transaction processing of thepresent disclosure may be stored in computer-readable storage media suchas one or more of system memory 718 or other storage. Code orcomputer-readable instructions to implement the dynamic approaches forpayment gateway selection and payment transaction processing of thepresent disclosure may also be received via one or more interfaces andstored in memory. The operating system provided on computer system 700may be MS-DOS®, MS-WINDOWS®, OS/2®, OS X®, IOS®, ANDROID®, UNIX®,Linux®, or another operating system.

It should be appreciated that some consideration may be given tomonitoring system health for satellites in mid-earth orbit (MEO) orlow-earth orbit (LEO). There may be two specific types of MEO/LEO systemto be considered. The first may be one in which beams are of fixedlocation on the earth's surface, and the second may be one in whichbeams move across the earth's surface as the satellites move.

In the first type, the satellite antenna may be continually adjusted tomaintain the same beam positioning on the ground, and the beam may behanded over from a descending satellite to a rising satellite in somesynchronized manner. In this case, the terminal 110 or VSAT may includea tracking antenna, and may use knowledge of satellite ephemeris data,for example, to (i) keep its VSAT antenna pointed to the satellite inservice for the beam, and/or (ii) repoint its VSAT antenna when the nextsatellite takes over service for the beam. In this type of system, thedesign and solutions described above may still be implemented. Thehealth report may include a time range of the test and the satellite inuse during the test. It should be appreciated that the threshold forpre-qualification of a terminal based on link quality may have toconsider that weather may be directional. For example, a terminal mightquickly transition from a good to bad link due to position of thesatellite and rain clouds relative to the terminal, andpre-qualification may be performed and then testing later aborted due tolink degradation.

In the second type, the satellite antenna may project a fixeddownlink/uplink beam pattern, which moves across the surface of theearth as the satellite moves in its orbital path. The terminal 110 orVSAT may use its tracking antenna as above to follow the satellite inuse, and to transition to the next satellite which may be taking overcoverage of the VSAT location. In this case, there may be no notion toselect VSATs near beam center or beam-edge, as the beam center and edgemay continue to move. Thus, a terminal 110 may not be disqualified fromuse for test when the beam edge (and a consequent beam handover) comesnear.

In either case, if a health test fails possibly related to satellitelink quality, the failure may be due to the satellite 120 in use, thegateway 130 serving that satellite 120 at that time, impairments(weather, interference) tied to the VSAT antenna look-angle, or theadded reported information might be used for subsequent problemdiagnosis. In case there is a satellite handover during the test, thetest results may be grouped according to which satellite was used foreach test.

As mentioned above, what is shown and described with respect to thesystems and methods above are illustrative. While examples describedherein are directed to configurations as shown, it should be appreciatedthat any of the components described or mentioned herein may be altered,changed, replaced, or modified, in size, shape, and numbers, ormaterial, depending on application or use case, and adjusted formonitoring system health and/or detecting faults.

It should be appreciated that the systems and methods described hereinmay facilitate more reliable use of terminals to monitor system healthand/or detect system faults. It should also be appreciated that thesystems and methods, as described herein, may also include orcommunicate with other components not shown. For example, these mayinclude external processors, counters, analyzers, computing devices, andother measuring devices or systems. This may also include middleware(not shown) as well. The middleware may include software hosted by oneor more servers or devices. Furthermore, it should be appreciated thatsome of the middleware or servers may or may not be needed to achievefunctionality. Other types of servers, middleware, systems, platforms,and applications not shown may also be provided at the back-end tofacilitate the features and functionalities of the testing andmeasurement system.

Moreover, single components may be provided as multiple components, andvice versa, to perform the functions and features described herein. Itshould be appreciated that the components of the system described hereinmay operate in partial or full capacity, or it may be removed entirely.It should also be appreciated that analytics and processing techniquesdescribed herein with respect to the optical measurements, for example,may also be performed partially or in full by other various componentsof the overall system.

It should be appreciated that data stores may also be provided to theapparatuses, systems, and methods described herein, and may includevolatile and/or nonvolatile data storage that may store data andsoftware or firmware including machine-readable instructions. Thesoftware or firmware may include subroutines or applications thatperform the functions of the measurement system and/or run one or moreapplication that utilize data from the measurement or othercommunicatively coupled system.

The various components, circuits, elements, components, and interfaces,may be any number of mechanical, electrical, hardware, network, orsoftware components, circuits, elements, and interfaces that serves tofacilitate communication, exchange, and analysis data between any numberof or combination of equipment, protocol layers, or applications. Forexample, the components described herein may each include a network orcommunication interface to communicate with other servers, devices,components or network elements via a network or other communicationprotocol.

Although examples are directed to satellite communication systems, suchas high throughput satellite (HTS) systems, it should be appreciatedthat the systems and methods described herein may also be used in othervarious systems and other implementations. For example, these mayinclude other various telecommunication test and measurement systems. Infact, there may be numerous applications in cable or opticalcommunication networks, not to mention fiber sensor systems that couldemploy the systems and methods as well.

It should be appreciated that the systems and methods described hereinmay also be used to help provide, directly or indirectly, measurementsfor distance, angle, rotation, speed, position, wavelength,transmissivity, and/or other related tests and measurements.

By leveraging existing customer terminals, the system and methodsdescribed herein may provide efficient processing techniques and acost-effective approach that may be readily integrated into various andexisting network equipment. The systems and methods described herein mayprovide mechanical simplicity and adaptability to small or largesatellite communication systems. Ultimately, the systems and methodsdescribed herein may increase efficiency, reduce cost, maximize existingequipment, minimize adverse effects of traditional systems, and improvemonitoring capabilities for system health and detecting faults.

What has been described and illustrated herein are examples of thedisclosure along with some variations. The terms, descriptions, andfigures used herein are set forth by way of illustration only and arenot meant as limitations. Many variations are possible within the scopeof the disclosure, which is intended to be defined by the followingclaims—and their equivalents—in which all terms are meant in theirbroadest reasonable sense unless otherwise indicated.

1. A system, comprising: a processor; a memory storing instructions,which when executed by the processor, cause the processor to: select,from a plurality of terminals, a subset of terminals to perform systemoperation tests using at least one of a semi-static pre-qualificationtechnique and a dynamic pre-qualification technique; perform systemoperation tests using the selected subset of terminals; and reportresults from the system operation test using the selected subset ofterminals.
 2. The system of claim 1, wherein the semi-staticpre-qualification technique comprises selecting a potential subset ofterminals to perform system operation tests based on at least one of thefollowing pre-qualification factors: terminal located within a targetbeam, configured permission, terminal capability, terminal capacity,service plan, channel mapping, monitoring priority, and in-beamlocation.
 3. The system of claim 1, wherein the dynamicpre-qualification technique comprises selecting the subset of terminalsto perform system operation tests based on the following: select apotential subset of terminals to perform system operation tests;transmit a dynamic pre-qualification query to each terminal from theselected potential subset of terminals; receive at least one queryresponse from each of the terminals; determine sufficiency of each ofthe received at least one query responses; and select the subset ofterminals to perform system operation tests based on the sufficiency ofthe received query responses.
 4. The system of claim 3, wherein thequery response is based on at least one status self-check performed byeach of the terminals, wherein the status self-check is used to helpdetermine whether the terminal is able to be used to perform systemoperation tests, the status self-check comprising at least one ofterminal state, user activity, transmission link quality, andtransmission link reliability.
 5. The system of claim 3, wherein thesufficiency of each of the received at least one query responses isbased on the at least one of the status self-check meeting apredetermined threshold or responsiveness of the terminal to the dynamicpre-qualification query.
 6. The system of claim 3, wherein the memorystoring instructions further comprises: performing, in response to thedetermination that at least one query responses is insufficient, atleast one of the following actions: generate an alarm or notification;delay the dynamic pre-qualification technique; and abort the dynamicpre-qualification technique.
 7. The system of claim 3, wherein selectingthe subset of terminals to perform system operation tests comprises:disqualifying terminals associated with insufficient query responses;filtering out disqualified terminals from the subset of terminals toperform system operation tests; and adding qualified terminals into thesubset of terminals to perform system operation tests.
 8. The system ofclaim 7, wherein selecting the subset of terminals to perform systemoperation tests further comprises: prioritizing the qualified terminalswithin the subset of terminals to perform system operation tests.
 9. Thesystem of claim 1, wherein system operation tests comprises at least oneof: traffic tests, business link tests, application tests, forwardchannel coverage tests, and return channel coverage tests.
 10. Thesystem of claim 9, wherein at least one of the traffic tests is usedsuch that user volume quota is not consumed by test traffic.
 11. Thesystem of claim 1, wherein the results of the system operation tests arereported with at least one of the following: an overall pass-failresult, a pass-fail result for each individual system operation testwith specific measure values, specific measured values for whichpass-fail is determined based on comparing to predetermined thresholds,and a time of the performed system operation test.
 12. The system ofclaim 1, wherein the memory storing instructions further comprises:determining potential system operation issues based on the results ofthe system operation tests using the selected subset of terminals; andgenerating at least one alarm or notification based on the determinationof potential system operation issues.
 13. A method for monitoringoperational status and detecting faults in a satellite system,comprising: selecting, by a processor, a subset of terminals, from aplurality of terminals, to perform system operation tests, whereinselecting the subset of terminals uses at least one of a semi-staticpre-qualification technique and a dynamic pre-qualification technique;performing system operation tests using the selected subset ofterminals; and reporting results from the system operation test usingthe selected subset of terminals.
 14. The method of claim 13, whereinthe semi-static pre-qualification technique comprises selecting apotential subset of terminals to perform system operation tests based onat least one of the following pre-qualification factors: terminallocated within a target beam, configured permission, terminalcapability, terminal capacity, service plan, channel mapping, monitoringpriority, and in-beam location.
 15. The method of claim 13, wherein thedynamic pre-qualification technique comprises selecting the subset ofterminals to perform system operation tests by: identifying a potentialsubset of terminals to perform system operation tests; transmitting adynamic pre-qualification query to each terminal from the identifiedpotential subset of terminals; receiving at least one query responsefrom each of the terminals; determining sufficiency of each of thereceived at least one query responses; and selecting the subset ofterminals to perform system operation tests based on the sufficiency ofthe received query responses.
 16. The method of claim 15, wherein thequery response is based on at least one status self-check performed byeach of the terminals, wherein the status self-check is used to helpdetermine whether the terminal is able to be used to perform systemoperation tests, the status self-check comprising at least one of:terminal state, user activity, transmission link quality, andtransmission link reliability.
 17. The method of claim 15, wherein thesufficiency of each of the received at least one query responses isbased on the at least one of the status self-check meeting apredetermined threshold and responsiveness of the terminal to thedynamic pre-qualification query.
 18. The method of claim 15, furthercomprising: performing, in response to the determination that at leastone query responses is insufficient, at least one of the followingactions: generate an alarm or notification; delay the dynamicpre-qualification technique; and abort the dynamic pre-qualificationtechnique. determining potential system operation issues based on theresults of the system operation tests using the selected subset ofterminals; and generating at least one alarm or notification based onthe determination of potential system operation issues.
 19. Anon-transitory computer-readable storage medium having an executablestored thereon, which when executed instructs a processor to perform amethod as follows: selecting, from a plurality of terminals, a subset ofterminals to perform system operation tests, wherein selecting thesubset of terminals uses at least one of a semi-static pre-qualificationtechnique and a dynamic pre-qualification technique; performing systemoperation tests using the selected subset of terminals; and reportingresults from the system operation test using the selected subset ofterminals.
 20. The non-transitory computer-readable storage medium ofclaim 19, wherein: the semi-static pre-qualification technique comprisesselecting a potential subset of terminals to perform system operationtests based on at least one of the following pre-qualification factors:terminal located within a target beam, configured permission, terminalcapability, terminal capacity, service plan, channel mapping, monitoringpriority, and in-beam location; and the dynamic pre-qualificationtechnique comprises selecting the subset of terminals to perform systemoperation tests by: identifying a potential subset of terminals toperform system operation tests; transmitting a dynamic pre-qualificationquery to each terminal from the identified potential subset ofterminals; receiving at least one query response from each of theterminals; determining sufficiency of each of the received at least onequery responses; and selecting the subset of terminals to perform systemoperation tests based on the sufficiency of the received queryresponses.